Dynomotion

Group: DynoMotion Message: 10972 From: Hardy Family Date: 1/31/2015
Subject: TCC floating point comparison bug
Found some wierdness, running KMotion 4.32 on Win7: see the following code:

typedef struct
{
    float    spd;
    float    backspd;
    double  postmove;
    int        limsw;
    enum
    {
        S_FWD,
        S_WAITHIT,
        S_BACK,
        S_WAITOFF,
        S_WAITPOST,
        S_DONE
    } state;
} home_t;

void ref_axes(unsigned amask, float spd)
{
    home_t h[N_AXES];
    int i;
    int running = 0;
   
    for (i = 0; i < N_AXES; ++i)
    {
        h[i].state = S_DONE;
        h[i].limsw = chan[i].LimitSwitchPosBit;
        h[i].spd = 0.;
        if (amask & (1u<<i))
        {
            // Doing this one.  For now, use these defaults...
            h[i].state = S_FWD;
            h[i].spd = spd;
            h[i].backspd = -spd*0.125;
            h[i].postmove = -MM_TO_STEPS(2.);
            if (h[i].postmove < 0.)
                printf("Post moving axis %d (neg) %g\n", i, h[i].postmove);
            if (h[i].postmove == 0.)
                printf("Post moving axis %d (zero) %g\n", i, h[i].postmove);
            if (h[i].postmove > 0.)
                printf("Post moving axis %d (pos) %g\n", i, h[i].postmove);
           
            ++running;
        }
    }
   // blah blah...
}


Basically implementing a state machine for reffing one or more axes simultaneously.  The strange thing is that, even though I set the postmove (double) field to -2000, the second of the debug printf's gets run (not the first!).  Output on the KMotion console is:

Post moving axis 2 (zero) -2000

So it appears the floating point comparison in the if() is not being computed correctly.  Bit of a worry!

Regards,
AB

Group: DynoMotion Message: 10987 From: mean_taipan Date: 2/2/2015
Subject: Re: TCC floating point comparison bug
Further to the above, I found that if the value is assigned to a temporary variable, the problem goes away.

So the work-around is to write

  double temp;

  ...

  temp = h[i].postmove;
  if (temp < 0.)
     ...

Regards,
AB



Group: DynoMotion Message: 10988 From: Tom Kerekes Date: 2/2/2015
Subject: Re: TCC floating point comparison bug
Hi AB,

Yes this seems to be a bug with our compiler.  We will need to have some time to look into it.  This is the simplest code that we have found that duplicates the problem:

#include "KMotionDef.h"

typedef struct
{
    float    spd;
    double  postmove;
    int        limsw;
} home_t;

home_t h[1];

main()
{
    int i=0;
    h[i].postmove = -2000;
    if (h[i].postmove == 0.0)
        printf("(zero)\n");
}

Regards
TK

Group: DynoMotion Message: 10990 From: Hardy Family Date: 2/2/2015
Subject: Re: TCC floating point comparison bug
Yes, it seems to require an indexing operation with an int variable index [i], and the field must be a double (float seems to work), and the field needs something before and after (doesn't seem to matter what types).  Curious!

Regards,
AB


On Mon, Feb 2, 2015 at 11:48 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi AB,

Yes this seems to be a bug with our compiler.  We will need to have some time to look into it.  This is the simplest code that we have found that duplicates the problem:

#include "KMotionDef.h"

typedef struct
{
    float    spd;
    double  postmove;
    int        limsw;
} home_t;

home_t h[1];

main()
{
    int i=0;
    h[i].postmove = -2000;
    if (h[i].postmove == 0.0)
        printf("(zero)\n");
}

Regards
TK

Group: DynoMotion Message: 11045 From: Tom Kerekes Date: 2/8/2015
Subject: Re: TCC floating point comparison bug
Hi AB,

This should fix the issue.  If you get a chance please verify it works for you and doesn't cause any other issue.  Source file is there also if needed.


Regards
TK

Group: DynoMotion Message: 11046 From: Hardy Family Date: 2/8/2015
Subject: Re: TCC floating point comparison bug
Great!  I'll give it a try out tomorrow (Monday).

Do you know of any C67 disassembler?  I realize Code Composer has one, but I don't really want to plonk down the $750 for it just to debug the differences between TCC67.exe and the new (Linux) version.

Regards,
AB


On Sun, Feb 8, 2015 at 9:30 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi AB,

This should fix the issue.  If you get a chance please verify it works for you and doesn't cause any other issue.  Source file is there also if needed.


Regards
TK

Group: DynoMotion Message: 11047 From: Tom Kerekes Date: 2/8/2015
Subject: Re: TCC floating point comparison bug
Hi AB,

I don't know of any disassembler other than CCS.  They usually offer a free 30 day trial period.

We forked from the main TCC branch a few years ago.  I fear it would be a big job to reconcile all their changes with our changes.  I don't know of anyone besides us who cares about using TCC for the C67xx processor.

The Debug Version of TCC67 outputs a crude form of Assembly intermixed with the source code tokens it discovers.  That might help show the differences.  Look for a TCC67_out.txt file in the directory of the executable.

For example EnableAxisDest(1,ch1->Dest);  shows as:


                                     EnableAxisDest
                                     (
                                     (
                                     1
                                     ,
156C  020000A8 MVKL. 1 4 0
1570  02000068 MVKH. 1 4 0
1574  023C54F4 STW.D SP POST DEC 4 0 0
                                     ch1
                                     ->
1578  00000028 MVKL. 0 105 0
157C  00000068 MVKH. 0 105 0
1580  01000264 LDW.D * 105 0 0
1584  00006000 NOP 4 0 0
                                     Dest
1588  01801C28 MVKL. 56 1 0
158C  01800068 MVKH. 56 1 0
1590  010C4078 ADD.L 0 1 0
                                     )
1594  02080366 LDDW.D * 0 6 0
1598  00008000 NOP 5 0 0
159C  023C54F6 STW.D SP POST DEC 6 0 0
15A0  02BC62F6 STW.D +* 7 106 3
                                     ;
15A4  023C33E6 LDDW.D SP PRE INC 6 0 0
15A8  023C52E4 LDW.D SP PRE INC 4 0 0
15AC  00000028 MVKL. 0 105 0
15B0  00000068 MVKH. 0 105 0
15B4  00001362 B.S2 0 -1 105
15B8  0180002A MVKL. 0 107 0
15BC  0180006A MVKH. 0 107 0
15C0  00004000 NOP 3 0 0


Regards
TK

Group: DynoMotion Message: 11063 From: Hardy Family Date: 2/11/2015
Subject: Re: TCC floating point comparison bug
Hi Tom,

I finally got around to testing this: saved the new TCC67.exe (from the link provided above) to my c:\kmotion432\KMotion\release\TCC67.exe.  I'm running Win7.

Unfortunately, it is still showing the original problem with the above (simplified) test code.  I also patched the same changes into my Ubuntu x86_64 build and got the same behavior.

Is the .exe file the only change?  I would think so, but just checking.  Also, is that "release" folder the correct location?

Regards,
AB


On Sun, Feb 8, 2015 at 10:33 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi AB,

I don't know of any disassembler other than CCS.  They usually offer a free 30 day trial period.

We forked from the main TCC branch a few years ago.  I fear it would be a big job to reconcile all their changes with our changes.  I don't know of anyone besides us who cares about using TCC for the C67xx processor.

The Debug Version of TCC67 outputs a crude form of Assembly intermixed with the source code tokens it discovers.  That might help show the differences.  Look for a TCC67_out.txt file in the directory of the executable.

For example EnableAxisDest(1,ch1->Dest);  shows as:


                                     EnableAxisDest
                                     (
                                     (
                                     1
                                     ,
156C  020000A8 MVKL. 1 4 0
1570  02000068 MVKH. 1 4 0
1574  023C54F4 STW.D SP POST DEC 4 0 0
                                     ch1
                                     ->
1578  00000028 MVKL. 0 105 0
157C  00000068 MVKH. 0 105 0
1580  01000264 LDW.D * 105 0 0
1584  00006000 NOP 4 0 0
                                     Dest
1588  01801C28 MVKL. 56 1 0
158C  01800068 MVKH. 56 1 0
1590  010C4078 ADD.L 0 1 0
                                     )
1594  02080366 LDDW.D * 0 6 0
1598  00008000 NOP 5 0 0
159C  023C54F6 STW.D SP POST DEC 6 0 0
15A0  02BC62F6 STW.D +* 7 106 3
                                     ;
15A4  023C33E6 LDDW.D SP PRE INC 6 0 0
15A8  023C52E4 LDW.D SP PRE INC 4 0 0
15AC  00000028 MVKL. 0 105 0
15B0  00000068 MVKH. 0 105 0
15B4  00001362 B.S2 0 -1 105
15B8  0180002A MVKL. 0 107 0
15BC  0180006A MVKH. 0 107 0
15C0  00004000 NOP 3 0 0


Regards
TK

Group: DynoMotion Message: 11064 From: Hardy Family Date: 2/11/2015
Subject: Re: TCC floating point comparison bug
Also it would greatly help if you could compile a version of TCC67 with the _DEBUG flag set.  I have my x86_64 version built with this, but I would like to be able to compare assembler dumps.

Regards,
AB


On Wed, Feb 11, 2015 at 12:20 PM, Hardy Family <hardy.woodland.cypress@...> wrote:
Hi Tom,

I finally got around to testing this: saved the new TCC67.exe (from the link provided above) to my c:\kmotion432\KMotion\release\TCC67.exe.  I'm running Win7.

Unfortunately, it is still showing the original problem with the above (simplified) test code.  I also patched the same changes into my Ubuntu x86_64 build and got the same behavior.

Is the .exe file the only change?  I would think so, but just checking.  Also, is that "release" folder the correct location?

Regards,
AB


On Sun, Feb 8, 2015 at 10:33 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi AB,

I don't know of any disassembler other than CCS.  They usually offer a free 30 day trial period.

We forked from the main TCC branch a few years ago.  I fear it would be a big job to reconcile all their changes with our changes.  I don't know of anyone besides us who cares about using TCC for the C67xx processor.

The Debug Version of TCC67 outputs a crude form of Assembly intermixed with the source code tokens it discovers.  That might help show the differences.  Look for a TCC67_out.txt file in the directory of the executable.

For example EnableAxisDest(1,ch1->Dest);  shows as:


                                     EnableAxisDest
                                     (
                                     (
                                     1
                                     ,
156C  020000A8 MVKL. 1 4 0
1570  02000068 MVKH. 1 4 0
1574  023C54F4 STW.D SP POST DEC 4 0 0
                                     ch1
                                     ->
1578  00000028 MVKL. 0 105 0
157C  00000068 MVKH. 0 105 0
1580  01000264 LDW.D * 105 0 0
1584  00006000 NOP 4 0 0
                                     Dest
1588  01801C28 MVKL. 56 1 0
158C  01800068 MVKH. 56 1 0
1590  010C4078 ADD.L 0 1 0
                                     )
1594  02080366 LDDW.D * 0 6 0
1598  00008000 NOP 5 0 0
159C  023C54F6 STW.D SP POST DEC 6 0 0
15A0  02BC62F6 STW.D +* 7 106 3
                                     ;
15A4  023C33E6 LDDW.D SP PRE INC 6 0 0
15A8  023C52E4 LDW.D SP PRE INC 4 0 0
15AC  00000028 MVKL. 0 105 0
15B0  00000068 MVKH. 0 105 0
15B4  00001362 B.S2 0 -1 105
15B8  0180002A MVKL. 0 107 0
15BC  0180006A MVKH. 0 107 0
15C0  00004000 NOP 3 0 0


Regards
TK

Group: DynoMotion Message: 11065 From: Hardy Family Date: 2/12/2015
Subject: Re: TCC floating point comparison bug
I tried the patched TCC67.exe on an actual machine.  It seems to be seriously wrong (going into la-la land) whenever I have any of the indexed array accesses.  I can kill the thread and it seems to recover, but can't actually run that program.

Regards,
SJH


On Wed, Feb 11, 2015 at 12:48 PM, Hardy Family <hardy.woodland.cypress@...> wrote:
Also it would greatly help if you could compile a version of TCC67 with the _DEBUG flag set.  I have my x86_64 version built with this, but I would like to be able to compare assembler dumps.

Regards,
AB


On Wed, Feb 11, 2015 at 12:20 PM, Hardy Family <hardy.woodland.cypress@...> wrote:
Hi Tom,

I finally got around to testing this: saved the new TCC67.exe (from the link provided above) to my c:\kmotion432\KMotion\release\TCC67.exe.  I'm running Win7.

Unfortunately, it is still showing the original problem with the above (simplified) test code.  I also patched the same changes into my Ubuntu x86_64 build and got the same behavior.

Is the .exe file the only change?  I would think so, but just checking.  Also, is that "release" folder the correct location?

Regards,
AB


On Sun, Feb 8, 2015 at 10:33 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi AB,

I don't know of any disassembler other than CCS.  They usually offer a free 30 day trial period.

We forked from the main TCC branch a few years ago.  I fear it would be a big job to reconcile all their changes with our changes.  I don't know of anyone besides us who cares about using TCC for the C67xx processor.

The Debug Version of TCC67 outputs a crude form of Assembly intermixed with the source code tokens it discovers.  That might help show the differences.  Look for a TCC67_out.txt file in the directory of the executable.

For example EnableAxisDest(1,ch1->Dest);  shows as:


                                     EnableAxisDest
                                     (
                                     (
                                     1
                                     ,
156C  020000A8 MVKL. 1 4 0
1570  02000068 MVKH. 1 4 0
1574  023C54F4 STW.D SP POST DEC 4 0 0
                                     ch1
                                     ->
1578  00000028 MVKL. 0 105 0
157C  00000068 MVKH. 0 105 0
1580  01000264 LDW.D * 105 0 0
1584  00006000 NOP 4 0 0
                                     Dest
1588  01801C28 MVKL. 56 1 0
158C  01800068 MVKH. 56 1 0
1590  010C4078 ADD.L 0 1 0
                                     )
1594  02080366 LDDW.D * 0 6 0
1598  00008000 NOP 5 0 0
159C  023C54F6 STW.D SP POST DEC 6 0 0
15A0  02BC62F6 STW.D +* 7 106 3
                                     ;
15A4  023C33E6 LDDW.D SP PRE INC 6 0 0
15A8  023C52E4 LDW.D SP PRE INC 4 0 0
15AC  00000028 MVKL. 0 105 0
15B0  00000068 MVKH. 0 105 0
15B4  00001362 B.S2 0 -1 105
15B8  0180002A MVKL. 0 107 0
15BC  0180006A MVKH. 0 107 0
15C0  00004000 NOP 3 0 0


Regards
TK

Group: DynoMotion Message: 11080 From: Tom Kerekes Date: 2/14/2015
Subject: Re: TCC floating point comparison bug
Hi SJH,

Strange it seems to work well for me.  Actually I found a moderately complex C program to perform a Simplex Optimization Problem as a Compiler test.  It seems to have a lot of double precision floating point Matrix operations and Structure offsets.  I compiled/ran using Microsoft Visual Studio compiler and captured the result vector.  Then I compiled/ran using TCC67 to compare.  It actually did show a new bug regarding storing the result of certain double precision floating point conditional comparisons.  I believe this is fixed.  I updated the files in the Patch Directory.  Also included is the Simplex.c program.  Also a Debug binary that I thought you said you wanted.  Please run the Simplex.c file and see if the last two lines are below as they are for me:

Optimal vector  at x1=0, x2=15.00, x3=0, x4=25.00, x5=0, x6=0, x7=20.00,
Correct Answer 145 x1=0, x2=15.00, x3=0, x4=25.00, x5=0, x6=0, x7=20.00,


Thanks
TK

Group: DynoMotion Message: 11085 From: Hardy Family Date: 2/14/2015
Subject: Re: TCC floating point comparison bug
Tom,

I ran simplex.c on old and new compiler.  The old compiler shows some assertion failures, and the new one does not.  Both give the same result (as does my Linux port).

Regarding the original problem, it is still not fixed.  Here is some test code I am running:

#include "KMotionDef.h"


typedef struct
{
    float    spd;
    double  postmove;
    int        limsw;
} home_t;

home_t h[1];

main()
{
    int i=0;
    double p = -2000.0;
    h[i].spd = 456;
    h[i].postmove = -2000;
    h[i].limsw = 123;
    if (h[i].postmove == 0.0)
        printf("(zero) - bad\n");
    else
        printf("(non-zero) - good\n");
    printf("Values are %g, %g, %d\n", h[i].spd, h[i].postmove, h[i].limsw);
    printf("postmove = %g\n", h[i].postmove);
    printf("constant = %g\n", -2000.0);
    printf("double = %g\n", p);
    p = h[i].postmove;
    printf("double = %g should be -2000\n", p);
    p = h[i].postmove + 10000.0;
    printf("double = %g  should be 8000\n", p);

}


And here is the result on the console:

(zero) - bad
Values are 456, 0, 123
postmove = 0
constant = -2000
double = -2000
double = 0 should be -2000
double = 10000  should be 8000


Interestingly, with the original compiler, I get the following result:

Console: (zero) - bad
Console: Values are 456, -2000, 123
Console: postmove = -2000
Console: constant = -2000
Console: double = -2000
Console: double = -2000 should be -2000
Console: double = 8000  should be 8000


(Note: running the above on Linux, hence the extra message prefix, but same result on Win7).  So the printf's work, but the comparison is still bad.

Regards,
SJH


On Sat, Feb 14, 2015 at 11:51 AM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

Strange it seems to work well for me.  Actually I found a moderately complex C program to perform a Simplex Optimization Problem as a Compiler test.  It seems to have a lot of double precision floating point Matrix operations and Structure offsets.  I compiled/ran using Microsoft Visual Studio compiler and captured the result vector.  Then I compiled/ran using TCC67 to compare.  It actually did show a new bug regarding storing the result of certain double precision floating point conditional comparisons.  I believe this is fixed.  I updated the files in the Patch Directory.  Also included is the Simplex.c program.  Also a Debug binary that I thought you said you wanted.  Please run the Simplex.c file and see if the last two lines are below as they are for me:

Optimal vector  at x1=0, x2=15.00, x3=0, x4=25.00, x5=0, x6=0, x7=20.00,
Correct Answer 145 x1=0, x2=15.00, x3=0, x4=25.00, x5=0, x6=0, x7=20.00,


Thanks
TK

Group: DynoMotion Message: 11124 From: Tom Kerekes Date: 2/21/2015
Subject: Re: TCC floating point comparison bug
Hi SJH,

Hopefully the compiler is now properly fixed.  Files are updated in the same place:
 
The Simplex.c test now includes both the Simplex Test and your (Indexed,-offset-double) test to test both.

Please try it again.

Thanks
TK



Group: DynoMotion Message: 11128 From: Hardy Family Date: 2/24/2015
Subject: Re: TCC floating point comparison bug
Hi Tom,

The fix seems to work in tcc67.exe.  Excellent!

I merged the changes into my Linux version, and it fixes the same problem there, except that I am getting some assertion failures in simplex.c that are not present in the Windows version (my problem, of course) even though the output is correct.  In order to debug that difference, I pulled down your debug build of tcc67.  Unfortunately, it crashes when I try to run it, getting the following info (from Wine).  Looks like there is some stack corruption with all those hex CCs (maybe related to the similar error in genuine Windows, see below)

  wine: Unhandled page fault on read access to 0xcccccccc at address 0x5d98f0 (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0xcccccccc in 32-bit code (0x005d98f0).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:005d98f0 ESP:0032f064 EBP:0032f15c EFLAGS:00010246(  R- --  I  Z- -P- )
 EAX:cccccccc EBX:7b894ff4 ECX:cccccccc EDX:0071e6e0
 ESI:7ffdf000 EDI:0032f15c
Stack dump:
0x0032f064:  004face7 cccccccc 0032f298 7ffdf000
0x0032f074:  7b894ff4 cccccccc cccccccc cccccccc
0x0032f084:  cccccccc cccccccc cccccccc cccccccc
0x0032f094:  cccccccc cccccccc cccccccc cccccccc
0x0032f0a4:  cccccccc cccccccc cccccccc cccccccc
0x0032f0b4:  cccccccc cccccccc cccccccc cccccccc
000c: sel=0067 base=00000000 limit=00000000 16-bit r-x
Backtrace:
=>0 0x005d98f0 in tcc67-debug (+0x1d98f0) (0x0032f15c)
  1 0x004eaf75 in tcc67-debug (+0xeaf74) (0x0032f298)
  2 0x004f6332 in tcc67-debug (+0xf6331) (0x0032f5c4)
  3 0x004ff5c1 in tcc67-debug (+0xff5c0)

If you wouldn't mind, please see if you can fix that.  Note that it doesn't seem to depend on the C code being compiled.

When running on genuine Windows, using KMotion to compile using the debug compiler I get the following (screenshot):

https://www.dropbox.com/s/k11pwglbegnonfl/Screenshot%202015-02-24%2012.12.22.png?dl=0

Regards,
SJH



On Sat, Feb 21, 2015 at 5:06 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

Hopefully the compiler is now properly fixed.  Files are updated in the same place:
 
The Simplex.c test now includes both the Simplex Test and your (Indexed,-offset-double) test to test both.

Please try it again.

Thanks
TK



Group: DynoMotion Message: 11129 From: Tom Kerekes Date: 2/24/2015
Subject: Re: TCC floating point comparison bug
Hi SJH,

Thanks but I can't duplicate the failure on my system.  I downloaded the debug Version from the patch link and placed it into a KMotion432\KMotion\Release directory and it works without any problem.

It might be the Microsoft Debug DLLs for the version of Visual Studio you have?  Do you have VS 2008 loaded on your system?

But actually if all you need is that disassemby ou put you can turn that on with this define in the Release Version:

#ifdef _DEBUG
#define ASSEMBLY_LISTING_C67
#endif


I created a Release Version on the Patch Directory compiled with that defined.

Regards
TK

Group: DynoMotion Message: 11130 From: Hardy Family Date: 2/24/2015
Subject: Re: TCC floating point comparison bug
Well it's probably my ignorance of Windows.  I'm actually running a fairly clean Win7 install under a virtual machine (VM player) on my Linux laptop.  So no VS as far as I know.  Does the debug version depend on having some DLLs installed?  That would explain it...

Anyway, I think I can use the version with the asm listing (that's all I really need, the rest will be all Greek to me), so don't worry about it.

Regards,
SJH


On Tue, Feb 24, 2015 at 1:07 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

Thanks but I can't duplicate the failure on my system.  I downloaded the debug Version from the patch link and placed it into a KMotion432\KMotion\Release directory and it works without any problem.

It might be the Microsoft Debug DLLs for the version of Visual Studio you have?  Do you have VS 2008 loaded on your system?

But actually if all you need is that disassemby ou put you can turn that on with this define in the Release Version:

#ifdef _DEBUG
#define ASSEMBLY_LISTING_C67
#endif


I created a Release Version on the Patch Directory compiled with that defined.

Regards
TK